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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal and the present application is 
CardinalCommerce Corporation (formally CardinalCommerce.com, Inc.), by way of an 
Assignment recorded in the U.S. Patent and Trademark Office at Reel 010617, Frame 
0479. 
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II. RELATED APPEALS AND INTERFERENCES 

In this application, a prior appeal was filed. See the Notice of Appeal filed on or 
about July 12, 2005 and the corresponding amended Appeal Brief filed on or about 
December 30, 2005. However, in response to the aforementioned amended Appeal 
Brief, prosecution of the present application was reopened by patent office. Other than 
the foregoing, there are no prior or pending appeals, interferences or judicial 
proceedings, known to Appellant, Appellant's representative, or the Assignee, that may 
be related to, or which will directly affect or be directly affected by or have a bearing 
upon the Board's decision in the pending appeal. 
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III. STATUS OF CLAIMS 

Claims 23, 24, 26-36 and 38-42 are on appeal. 
Claims 23, 24, 26-36 and 38-42 are pending. 
Claims 23, 24, 26-36 and 38-42 are rejected. 
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IV. STATUS OF AMENDMENTS 

No Amendment After Final Rejection has been filed. 



4 



Application No. 10/358,583 



V. SUMMARY OF CLAIMED SUBJECT MATTER 

^- Independent Claim 23 

Claim 23 is directed to a method of processing a transaction carried out over a 
networl< between a financial account holder and a participating entity. FIGURE 1 shows 
a centralized transaction coordinator 10 that administers among other processes an online 
shopping process 300 wherein buyers or consumers engage in online commercial 
transactions with merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the 
coordinator 10 having a presence on the Internet 50 or another like network. Similarly, a 
buyer 30 (e.g., a financial account holder) and a seller 20 (e.g., a participating entity) also 
have access to the network 50 over which the transaction is conducted. See page 6, line 
37 through page 7, line 6. 

The claimed method (e.g., the online shopping process 300 administered by the 
coordinator 10) includes receiving a purchase request of a buyer 30 from the 
participating entity (e.g., the seller 20) indicating that the buyer desires to carry out a 
transaction with the entity, the transaction including the buyer purchasing one or more 
selected items. FIGURES 6A and 6B show more detailed flow charts of two 
embodiments of the online shopping process 300. Note, the purchase request 352, in 
accordance with the claimed method, is received by the coordinator 10 and is sent from 
the seller 20. See page 15, lines 20-29. 

The claimed method also includes authenticating the buyer as the financial 
account holder. FIGURES 6A and 68 show the coordinator 10 administering an 
authentication process 310 and making a related determination 320 whether or not the 
buyer is the authentic account holder 30. See page 14, lines 1-10. 

Additionally, the claimed method includes establishing transaction fulfillment 
data, said transaction fulfillment data indicating a delivery destination for the selected 
items, wherein establishing the transaction fulfillment data includes using a previously 
obtained destination as the delivery destination for the selected items when an alternate 
destination is not obtained. FIGURES 6A and 68 show the coordinator 10 establishing 
the transaction fulfillment data at process 360. FIGURE 6C shows a more detailed flow 
chart of an exemplar/ embodiment of the fulfillment data establishing process 360. 
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Suitably, a user (i.e., buyer and/or account holder) pre-registers (e.g., via process 200 
as shown in FIGURES 1 and 4) with the coordinator 10 before using the online 
shopping process 300. During registration 200, optionally, a default delivery destination 
is established for the account holder and maintained by the coordinator 10. See page 
16, lines 16-19. For example, as shown in FIGURE 4, the default delivery destination 
may be supplied by the account holder 30 to the coordinator 10 along with the account 
holder registration data 202 or along with the additional account creation data 226. 

In any event, the coordinator 10 at process 360 established the transaction 
fulfillment data 362 which preferably includes a delivery destination. See page 16, lines 
7-10. Moreover, the previously obtained default destination is used to establish the 
fulfillment data 362 unless an alternate destination is obtained. See page 16, lines 19- 
25. 

Finally, the claimed method further includes: 

• communicating the transaction fulfillment data to the participating entity 
(FIGURES 6A and 6B show the transaction fulfillment data 362 being 
sent from the coordinator 10 to the seller 20 (i.e., the participating 
entity), see also page 17, lines 16-19); 

• receiving transaction details from the participating entity, said 
transaction details including a cost for the selected items (FIGURES 
6A and 6B show the transaction details 384 being received by the 
coordinator 10 from the seller 20 (i.e., the participating entity), see also 
page 17, lines 26-32 identifying the transaction details 384 as including 
a cost for the selected items); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 1 7. lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating entity (FIGURES 6A and 68 show the authorization code 



6 



Application No. 10/358,583 



392 being sent from the coordinator 10 to tlie seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

B. Independent Claim 26 

Clainn 26 is directed to a method of processing transactions carried out over a 
network between account holders and participating entities. FIGURE 1 shows a central 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 1 1-26. FIGURE 2 shows the coordinator 10 having 
a presence on the Internet 50 on another like network. Similarly, a buyer 30 (e.g., an 
account holder) and a seller 20 (e.g., a participating entity) also have access to the 
network 50 over which the transaction is conducted. See page 6, line 37 through page 7, 
line 6. 

The claimed method also includes obtaining restriction instructions from account 
holders. Suitably, a user (i.e., buyer and/or account holder) pre-registers (e.g., via 
process 200 as shown in FIGURES 1 and 4) with the coordinator 10 before using the 
online shopping process 300. Upon acceptance of a newly registered account holder, 
the coordinator 10 creates and maintains a record for the account holder 30, e.g., on the 
coordinator's database 14. See FIGURE 1 and page 11, lines 2-9. The account holder 
record includes, among other information, account privileges that restrict authorization 
of transactions in identified circumstances that are set by the account holder 30. 
Suitably, the coordinator 10 obtains the restriction instructions or related data that is 
stored in the coordinator's database 14 by the account holder accessing the 
coordinator's server 12 over the network 50 and customizing or setting their account 
privileges as they desire. See page 1 1 , Iines10-31 . 

Additionally, the claimed method also includes: 

• receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the 
entity, said transaction including the buyer purchasing one or more 
selected items (FIGURES 6A and 6B show the purchase request 352 
received by the coordinator 10 from the seller 20, see also page 15, 
lines 20-29); 
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• authenticating tlie buyer as an account holder (FIGURES 6A and 6B 
show the coordinator 10 administering an authentication process 310 
and making a related determination 320 whether or not the buyer is the 
authentic account holder 30, see also page 14, lines 1-10); 

• receiving transaction details from the participating entity, said 
transaction details including one or more terms for the purchase 
(FIGURES 6A and 6B show the transaction details 384 being received 
by the coordinator 10 from the seller 20 (i.e., the participating entity), 
see also page 17, lines 26-32); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 1 7, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating entity (FIGURES 6A and 68 show the authorization code 
392 being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

C. Independent Claim 31 

Claim 31 is directed to a method of processing transactions carried out over a 
network between account holders and participating entities. FIGURE 1 shows a central 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the coordinator 10 having 
a presence on the Internet 50 on another like network. Similarly, a buyer 30 (e.g., an 
account holder) and a seller 20 (e.g., a participating entity) also have access to the 
network 50 over which the transaction is conducted. See page 6, line 37 through page 7, 
line 6. 

The claimed method includes; 

• receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the 

8 



Application No. 10/358,583 



entity, said transaction including the buyer purcliasing one or more 
selected items (FIGURES 6A and 6B show the purchase request 352 
received by the coordinator 10 from the seller 20, see also page 15, 
lines 20-29); 

• authenticating the buyer as an account holder (FIGURES 6A and 6B 
show the coordinator 10 administering an authentication process 310 
and making a related determination 320 whether or not the buyer is the 
authentic account holder 30, see also page 14, lines 1-10); 

• receiving transaction details from the participating entity, said 
transaction details including a cost for the purchase (FIGURES 6A and 
6B show the transaction details 384 being received by the coordinator 
10 from the seller 20 (i.e., the participating entity), see also page 17, 
lines 26-32 identifying the transaction details 384 as including a cost 
for the selected items); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 68 show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 17, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating entity (FIGURES 6A and 68 show the authorization code 
392 being sent from the coordinator 10 to the seller 20 (i.e., the 
participating entity), see also page 18, lines 20-23). 

Additionally, the claimed authorizing step includes: transmitting the transaction 
details of the authenticated account holder to a funding source which determines if the 
account holder has one of sufficient funds on deposit with the funding source or 
sufficient credit available through the funding source to cover the cost of the purchase. 
See, e.g., page 17, line 35 through page 18, line 6, and page 18, lines 11-15. 

D. Independent Claim 32 

Claims 32 is directed to method of processing transactions carried out over a 
network between account holders and participating entities. FIGURE 1 shows a central 
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transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 1 1-26. FIGURE 2 shows the coordinator 10 having 
a presence on the Internet 50 on another like network. Similarly, a buyer 30 (e.g., an 
account holder) and a seller 20 (e.g., a participating entity) also have access to the 
network 50 over which the transaction is conducted. See page 6, line 37 through page 7, 
line 6. 

The claimed method includes: 

• receiving a request indicating that a buyer desires to carry out a 
transaction with a participating entity, said transaction including the 
buyer purchasing one or more selected items (FIGURES 6A and 6B 
show the purchase request 352 received by the coordinator 10 from 
the seller 20, see also page 15, lines 20-29); 

• authenticating the buyer as an account holder (FIGURES 6A and 6B 
show the coordinator 10 administering an authentication process 310 
and making a related determination 320 whether or not the buyer is the 
authentic account holder 30, see also page 14, lines 1-10); 

• receiving transaction details including one or more terms for the 
purchasing the selected items (FIGURES 6A and 6B show the 
transaction details 384 being received by the coordinator 10 from the 
seller 20 (i.e., the participating entity), see also page 17, lines 26-32 
identifying the transaction details 384 as including a cost for the 
selected items); 

• authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 68 show the 
coordinator 10 administering an authorization process 390 that 
establishes an authorization code 392, see also page 1 7, lines 27-29, 
page 17, line 35 through 18, line 6, and page 18, lines 12-15); and, 

• communicating the authorization code for the transaction to the 
participating merchant (FIGURES 6A and 68 show the authorization 
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code 392 being sent from the coordinator 10 to the seller 20 (i.e., the 

participating entity), see also page 18, lines 20-23). 
The claimed method also includes obtaining settlement information from the 
participating entity, said settlement information including the authorization code and 
transaction details for the completed transaction. FIGURE 1 shows a settlement 
process 400 also administered by the coordinator 10. See page 6, lines 23-26. FIGURE 
7 shows a more detailed flow chart of the settlement process 400. In particular, FIGURE 
7 shows the coordinator obtaining settlement information 402 from the seller 20 for a 
completed commercial transaction. See page 18, lines 24-27. The obtained settlement 
information 402 preferably includes the authorization code 392 and the corresponding 
transaction details 384 for the completed transaction in question. See page 19, lines 9- 
12. 

Additionally, the claimed method includes: confirming that the transaction details 
corresponding to the authorization code received with the settlement information are 
within a desired tolerance (see page 19, lines 12-24); and, communicating the 
confirmed settlement information 402b to a funding source 40 to effect reimbursement 
420 of the participating entity (e.g., the seller 20) and billing 410 of the account holder 
30 (see FIGURE 7 and page 19, lines 25-34). 

E. Independent Claim 41 

Claim 41 is directed to a system for processing a transaction carried out over a 
network between a financial account holder and a seller. FIGURE 1 shows a centralized 
transaction coordinator 10 that administers among other processes an online shopping 
process 300 wherein buyers or consumers engage in online commercial transactions with 
merchants or sellers. See page 6, lines 11-26. FIGURE 2 shows the coordinator 10 having 
a presence on the Internet 50 or another like network. Similarly, a buyer 30 (e.g., a 
financial account holder) and a seller 20 (e.g., a participating entity) also have access to 
the network 50 over which the transaction is conducted. See page 6, line 37 through page 
7, line 6. The coordinator 10 employs a server 12 and/or database 14 as the means to 
carry out the various functions of the online shopping process 300. 

The claimed system includes: 
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means for receiving a purchase request of a buyer from tlie seller 
indicating that the buyer desires to carry out a transaction with the seller, 
said transaction including the buyer purchasing one or more selected 
items (FIGURES 6A and 6B show the purchase request 352 received by 
the coordinator 10 from the seller 20, see also page 15, lines 20-29, and 
FIGURE 2 shows the coordinator's server 12 interconnected for 
communication via the network 50 with the seller's server 22 thereby 
providing the server 12 as the means to achieve the forgoing function); 
means for authenticating the buyer as the financial account holder 
(FIGURES 6A and 6B show the coordinator 10 administering an 
authentication process 310 and making a related determination 320 
whether or not the buyer is the authentic account holder 30, see also page 
14, lines 1-10, and FIGURE 2 shows the coordinator's server 12 
interconnected for communication via the network 50 with the buyer's 
computer 32 thereby providing the server 12 as the means to achieve the 
forgoing function); 

means for establishing transaction fulfillment data, said transaction 
fulfillment data indicating a delivery destination for the selected items 
(FIGURES 6A and 6B show the coordinator 10 at process 360 
establishing the transaction fulfillment data 362 which preferably includes 
a delivery destination, see also page 16, lines 7-10, FIGURE 2 shows the 
server 12 and/or database 14 employed by the coordinator 10 that 
administers the online shopping process 300 thereby providing the means 
to achieve the forgoing function, e.g., the server 12 provides for 
communication with the buyer 30 from which an alternate delivery 
destination is optionally received (see FIGURE 6C showing the process 
360 administered by the coordinator 10 including an option for delivery 
destination selection by a buyer, and FIGURE 2 showing the 
interconnection of the coordinator's server 12 and the buyer's computer 32 
via the network 50 for communication therebetween), and the database 14 
provides for storage of a default delivery address that may be employed to 
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establish the transaction fulfillment data (see FIGURE 2 and page 16, 
lines 16-19 and page 11, lines 2-4)); 

means for communicating the transaction fulfillment data to the seller 
(FIGURES 6A and 6B show the transaction fulfillment data 362 being sent 
from the coordinator 10 to the seller 20, see also page 17, lines 16-19, 
and FIGURE 2 shows the coordinator's server 12 interconnected for 
communication via the network 50 with the seller's server 22 thereby 
providing the server 12 as the means to achieve the forgoing function); 
means for receiving transaction details from the seller, said transaction 
details including a cost for the selected items (FIGURES 6A and 6B show 
the transaction details 384 being received by the coordinator 10 from the 
seller 20, see also page 17, lines 26-32 identifying the transaction details 
384 as including a cost for the selected items, and FIGURE 2 shows the 
coordinator's server 12 interconnected for communication via the network 
50 with the seller's server 22 thereby providing the server 12 as the 
means to achieve the forgoing function); 

means for authorizing completion of the transaction and establishing an 
authorization code therefor (FIGURES 6A and 6B show the coordinator 10 
executing an authorization process 390 that establishes an authorization 
code 392, see also page 17, lines 27-29, page 17, line 35 through 18, line 
6, and page 18, lines 12-15, and FIGURE 2 shows the server 12 and/or 
database 14 employed by the coordinator 10 that administers the online 
shopping process 300 thereby providing the means to achieve the 
forgoing function); and, 

means for communicating the authorization code for the transaction to the 
seller (FIGURES 6A and 68 show the authorization code 392 being sent 
from the coordinator 10 to the seller 20, see also page 18, lines 20-23, 
and FIGURE 2 shows the coordinator's server 12 interconnected for 
communication via the network 50 with the seller's server 22 thereby 
providing the server 12 as the means to achieve the forgoing function). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The following grounds of rejection are presented for review: 

Claims 23, 31, 36, 39, 41 and 42 stand rejected under 35 U.S.C. §1 03(a) as 
being unpatentable over U.S. Patent No. 6,456,984 to Demoff, et al. ("Demoff') in view 
of U.S. Patent No. 5,903,878 to Talati, et al. ("Talati"). 

Claim 24 stands rejected under 35 U.S.C. §1 03(a) as being unpatentable over 
Demoff in view of Talati as applied to claim 23, and further in view of U.S. Patent No. 
6,012,045 to Barzilai, et al. ("Barzilai"). 

Claims 26-30 and 38 stand rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Demoff in view of Talati as applied to claim 23, and further in view of 
U.S. Patent No. 6,226,624 to Watson, et al. ("Watson"). 

Claims 32-34 and 40 stand rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Demoff in view of Talati as applied to claim 31 , in view of U.S. Patent 
No. 6,315,193 to Hogan ("Hogan") and further in view of U.S. Patent No. 6,381,587 to 
Guzelsu ("Guzelsu"). 

Claim 35 stands rejected under 35 U.S.C. §1 03(a) as being unpatentable over 
Demoff in view of Talati in view of Hogan in view of Guzelsu as applied to claim 32, and 
further in view of U.S. Patent No. 5,657,388 to Weiss ("Weiss"). 
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VII. ARGUMENT 

A. The Combination of Talati with Demoff is Improper and 

Accordingly the Rejections of Claims 23. 24. 26-36 and 38- 
42 are Erroneous 

The rejections of the claims are erroneous. The foregoing rejections are all based 
totally or in part on the combination of Talati with Demoff. Insomuch as this combination 
is improper, the rejections are erroneous and should be withdrawn. 

It is well settled that the initial burden for establishing a prima facie case of 
obviousness rests upon the Examiner. See The Manual of Patent Examining Procedure 
(MPEP) §2142. The Examiner has not done so in this instance. Again, the MPEP is 
instructive on this point. Specifically, when making a rejection under 35 U.S.C. §103, the 
Examiner is required to set forth in the Office Action "the proposed modification of the 
applied reference(s) necessary to arrive at the claimed subject matter." See MPEP 
§706.02(1) (C). The Examiner in the present case has not fulfilled this requirement in the 
Office Action. Rather, the Examiner merely alleges that it would have been obvious to 
modify Demoff to include the steps as taught by Talati. Nowhere does the Office Action 
indicate with any specificity how Demoff is to be altered by Talati. That is to say, no 
modification of Demoff is proposed. Rather, the Office Action merely concludes that it 
would have been obvious to include the teachings of Talati in the teaching of Demoff. 
Such a conclusory unsupported allegation does not satisfy the requirements of MPEP 
§706.02(j) (0). Accordingly, the Office Action does not present a prima facie case of 
obviousness. The rejections of the claims under 35 U.S.C. §1 03(a) base upon the 
combination of Talati with Demoff, therefore, are erroneous and should be withdrawn. 

Additionally, independent claim 23 recites the step "receiving a purchase request 
of a buyer from the participating entity indicating that the buyer desires to carry out a 
transaction with the entity, said transaction including the buyer purchasing one or more 
selected items." As indicated above, the claimed method (e.g., the online shopping 
process 300 administered by the coordinator 10) includes receiving a purchase request 
of a buyer 30 from the participating entity (e.g., the seller 20) indicating that the buyer 
desires to carry out a transaction with the entity, the transaction including the buyer 
purchasing one or more selected items. FIGURES 6A and 6B show more detailed flow 
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charts of two embodiments of the online shopping process 300. Note, the purchase 
request 352, in accordance with the claimed method, is received by the coordinator 10 
and is sent from the seller 20 - not the buyer 30. See page 15, lines 20-29. Likewise, 
independent claims 26 (see, e.g., step a), 31 (see, e.g., step b), 32 (see, e.g., step a) 
and 41 (see, e.g., the means for receiving a purchase request) include similar steps, 
elements and/or features. 

In any event, the Examiner concedes that Demoff does not teach the foregoing. 
In fact, the Examiner expressly indicates that "Demoff does not explicitly teach receiving 
a purchase request of the buyer from the seller." See, e.g., page 3 of the Office Action 
dated 09/07/2007. Rather, the Examiner attempts to remedy this by impermissibly 
combining Talati with Demoff. 

Importantly, according to MPEP §2143.01 (VI), "If the proposed modification or 
combination of the prior art would change the principle of operation of the prior art 
invention being modified, then the teachings of the references are not sufficient to 
render the claims prima facie obvious." Combining Talati with Demoff would, in fact, 
impermissibly change the principle of operation of Demoff. Accordingly, such a 
combination is inappropriate and the rejections based wholly or in part thereon are 
fatally flawed. 

More specifically, Demoff is directed to system and/or method for providing 
temporary credit authorizations. Demoff proposes a system wherein a buyer requests 
from a service provider (presumably equated by the Examiner with the coordinator 10 of 
the present application) and is issued a temporary credit card number that the buyer 
then uses to make a specific purchase or transaction. Furthermore, to later identify the 
buyer, Demoff teaches that a unique personal ID is associated with the transaction 
when the temporary credit card number is requested by the buyer from the service 
provider. This unique ID is derived from either a session ID or a telephone number 
depending on the manner in which the buyer submitted the request for the temporary 
credit card number to the service provider. Accordingly, without the buyer making the 
request to the service provider (e.g., via an Internet connection or telephone call), no 
unique personal ID can be associated with the transaction, insomuch as no session ID 
or telephone number is established that can later be used to identify the buyer. That is 
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to say, without the unique personal ID (which is derived from the Internet session or 
telephone call between the buyer and the service provider when the buyer requests the 
temporary credit card number from the service provider), the invention of Demoff would 
not be able to later identify and/or authenticate the buyer when the transaction was 
completed. This is a fundamental principle of operation upon which the invention of 
Demoff relies. Accordingly, any proposed modification of Demoff that changes this 
principle of operation is inappropriate. That is to say, according to Demoff, the buyer 
must directly request the temporary credit card number from the service provider, or 
else, no unique personal ID can be generated. 

Nevertheless, the Office Action suggests combining Talati with Demoff. In 
particular, the Office Action states that "Talati teaches receiving a purchase request of 
the buyer from the seller." However, this is a selective reading of Talati, and the 
teaching is taken out of context. What Talati in fact teaches is that the buyer (i.e., 
originator) provides the seller (i.e., recipient) a transaction request that includes a credit 
card or account number (i.e., originator ID or OID) and in turn the recipient relays the 
request to the transaction administrator. Moreover, the buyer later validates the 
transaction using a unique transaction identifier (UTID) that they provided with the 
request. Accordingly, for the seller to provide the transaction request to the transaction 
administrator, the seller must first be provided the actual credit card or account number 
of the buyer. This is precisely the type of thing Demoff is attempting to guard against by 
issuing temporary credit card numbers in the first place. Consequently, modifying 
Demoff so that it employs the transaction request taught by Talati frustrates the very 
purpose and/or goal of the Demoff invention and in fact impermissibly changes the 
principle of operation of Demoff. Such a combination is clearly proscribed by MPEP 
§2143.01(V). 

Moreover, to the extent that when Demoff is so modified such that the service 
provider would now be receiving the alleged purchase request from the seller, then this 
eliminates the need for the buyer to make a direct request from the service provider, 
and accordingly, no session ID or telephone ID is obtained by the service provider from 
which a unique personal ID can be derived for later identifying and/or authenticating the 
buyer at the time the transaction is completed. In essence, such a modification would 
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render the invention of Demoff inoperable and/or unsatisfactory for its intended purpose. 
According to MPEP §21 43.01 (V), such modifications are also simply impermissible. 

Therefore, insomuch as all the claim rejections rely at least in part on the 
improper combination of Talati with Demoff, it is respectfully submitted that the 
rejections are fatally flawed and that in fact the claims define patentably over the prior 
art. More specifically, insomuch as it is improper to combine Talati with Demoff and 
Demoff otherwise admittedly fails to teach all the claimed elements (e.g., "Demoff does 
not explicitly teach receiving a purchase request of the buyer from the seller"), then it is 
respectfully submitted that the claims distinguish patentably over the art. 
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CONCLUSION 



For all of the reasons discussed above, It is respectfully submitted that the 
rejection(s) are in error and that the claims are in condition for allowance. For all of the 
above reasons, Appellants respectfully request this Honorable Board to reverse the 
rejection(s) of claims 23, 24, 26-36 and 38-42. 



:iew 

Fay Sharpe LLP 

1 100 Superior Avenue - Seventh Floor 
Cleveland, Ohio 44114-2579 
Telephone: (216) 861-5582 

Filed: April 22, 2008 



Respectfully submitted. 
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APPENDICES 

VIII. CLAIMS APPENDIX 

Claims involved in the Appeal are as follows: 
1-22. (Cancelled). 

23. (Previously Presented) A method of processing a transaction 
carried out over a network between a financial account holder and a participating entity, 
said method comprising the steps of: 

(a) receiving a purchase request of a buyer from the participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items; 

(b) authenticating the buyer as the financial account holder; 

(c) establishing transaction fulfillment data, said transaction fulfillment 
data indicating a delivery destination for the selected items, wherein establishing the 
transaction fulfillment data includes using a previously obtained destination as the 
delivery destination for the selected items when an alternate destination is not obtained; 

(d) communicating the transaction fulfillment data to the participating 

entity; 

(e) receiving transaction details from the participating entity, said 
transaction details including a cost for the selected items; 

(f) authorizing completion of the transaction and establishing an 
authorization code therefor; and, 

(g) communicating the authorization code for the transaction to the 
participating entity. 

24. (Original) The method according to claim 23, wherein 
establishing the fulfillment data further includes: 

obtaining an alternate destination from the buyer, said alternate 
destination being different from the previously obtained destination; 
transmitting a security question to the buyer; 
receiving a response to the secunty question from the buyer; and, 
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using the alternate destination as the delivery destination for the selected 
items when the response to the security question is accurate. 

25. (Cancelled). 

26. (Previously Presented) A method of processing transactions 
carried out over a network between account holders and participating entities, said 
method comprising the steps of: 

(a) obtaining restriction instructions from account holders; 

(b) receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items; 

(c) authenticating the buyer as an account holder; 

(d) receiving transaction details from the participating entity, said 
transaction details including one or more terms for the purchase; 

(e) authorizing completion of the transaction and establishing an 
authorization code therefor; and, 

(f) communicating the authorization code for the transaction to the 
participating entity. 

27. (Previously Presented) The method according to claim 26, 
wherein said restriction instructions block authorizing the completion of transactions with 
participating entities identified in the restriction instructions. 

28. (Original) The method according to claim 26, wherein said 
restriction instructions block authorizing the completion of recurring transactions which 
are not separately participated in by the account holder from whom the restnction 
instructions were obtained. 

29. (Previously Presented) The method according to claim 26, 
wherein authorizing completion of the transaction includes companng a cost of the 
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selected items to a threshold such that if the cost is less than or equal to the threshold 
authorization is given and if the cost if greater than the threshold authorization is denied. 

30. (Previously Presented) The method according to claim 29, 
wherein the threshold represents an amount selected from a group consisting of funds 
on deposit for the account holder, credit available to the account holder, and a value set 
via the obtained restriction instructions. 

31. (Previously Presented) A method of processing transactions 
carried out over a network between account holders and participating entities, said 
method comprising the steps of: 

(a) receiving a purchase request of a buyer from a participating entity 
indicating that the buyer desires to carry out a transaction with the entity, said 
transaction including the buyer purchasing one or more selected items; 

(b) authenticating the buyer as an account holder; 

(c) receiving transaction details from the participating entity, said 
transaction details including a cost for the purchase; 

(d) authorizing completion of the transaction and establishing an 
authorization code therefor, wherein authorizing completion of the transaction and 
establishing an authorization code therefor includes: 

transmitting the transaction details of the authenticated 
account holder directly to a funding source which determines if the 
account holder has one of sufficient funds on deposit with the funding 
source or sufficient credit available through the funding source to cover 
the cost of the purchase; and, 

receiving the authorization code from the funding source; 

and, 

(e) communicating the authonzation code for the transaction to the 
participating entity. 
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32. (Previously Presented) A method of processing transactions 
carried out over a networl< between account holders and participating entities, wherein 
said method comprises: 

(a) receiving a request indicating that a buyer desires to carry out a 
transaction with a participating entity, said transaction including the buyer purchasing 
one or more selected items; 

(b) authenticating the buyer as an account holder; 

(c) receiving transaction details including one or more terms for the 
purchasing the selected items; 

(d) authorizing completion of the transaction and establishing an 
authorization code therefor; 

(e) communicating the authorization code for the transaction to the 
participating merchant; 

(f) obtaining settlement information from the participating entity, said 
settlement information including the authorization code and transaction details for the 
completed transaction; 

(g) confirming that the transaction details corresponding to the 
authorization code received with the settlement information are within a desired 
tolerance; and, 

(h) communicating the confirmed settlement information to a funding 
source to effect reimbursement of the participating entity and billing of the account 
holder. 

33. (Previously Presented) The method according to claim 32, 
wherein obtaining the settlement information includes automatically captunng the 
settlement information from the participating entity upon an indication of delivery of the 
selected items. 

34. (Previously Presented) The method according to claim 32, 
wherein step (b) precedes step (a). 
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35. (Previously Presented) The method according to claim 32, 
wherein authenticating the buyer as an account holder includes: 

synchronizing a token with a periodically changing non-predictable code; 

providing the account holder with the token, said token displaying the 
periodically changing non-predictable code; 

receiving a code communicated by the buyer; and, 
comparing the received code with the periodically changing non-predictable code to 
authenticate the buyer as the account holder when the received code matches the 
periodically changing non-predictable code. 

36. (Previously Presented) The method according to claim 23, 
wherein the transactions are at least partially carried out over a public network. 

37. (Cancelled). 

38. (Previously Presented) The method according to claim 26, 
wherein the transactions are at least partially carried out over a public network. 

39. (Previously Presented) The method according to claim 31, 
wherein the transactions are at least partially carried out over a public network. 

40. (Previously Presented) The method according to claim 32, 
wherein the transactions are at least partially carried out over a public network. 

41 . (Previously Presented) A system for processing a transaction 
carried out over a network between a financial account holder and a seller, said system 
comprising: 

means for receiving a purchase request of a buyer from the seller 
indicating that the buyer desires to carry out a transaction with the seller, said 
transaction including the buyer purchasing one or more selected items; 

means for authenticating the buyer as the financial account holder; 
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means for establishing transaction fulfillment data, said transaction 
fulfillment data indicating a delivery destination for the selected items; 

means for communicating the transaction fulfillment data to the seller; 

means for receiving transaction details from the seller, said transaction 
details including a cost for the selected items; 

means for authorizing completion of the transaction and establishing an 
authorization code therefor; and, 

means for communicating the authorization code for the transaction to the 

seller. 

42. (Previously Presented) The system according to claim 41 , 
wherein the transactions are at least partially carried out over a public network. 
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IX. EVIDENCE APPENDIX 

Appellant, Appellant's representative, and/or the Assignee are aware of no 
evidence submitted under 37 CFR §§1.130, 1.1331, or 1.132 or of any other evidence 
entered by the Examiner and relied upon by the Appellant in the present appeal. 
Accordingly, the remainder of this page has been intentionally left blank. 



26 



Application No. 10/358,583 



X. RELATED PROCEEDINGS APPENDIX 

Appellant, Appellant's representative, and/or the Assignee are aware of no 
related proceeding in connection with this matter. Accordingly, the remainder of this 
page has been intentionally left blank. 
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